1. Field of the Invention
The present invention relates to a device controller that controls a device coupled to a computer, a method for controlling a device, and a program therefor.
Priority is claimed on Japanese Patent Application No. 2005-149746, filed May 23, 2005, the content of which is incorporated herein by reference.
2. Description of the Related Art
A device driver has been used for controlling a device that is connected to a computer. An operating system (OS) running on a computer provides a general-purpose interface for various device drivers. With the interface, when a new device is developed, this device is available from execution objects, such as application programs or the OS, by installing a device driver that supports the new device. A manufacturer of the device provides the device driver, and the OS provides application programs with the capability to control the device by means of a system call.
A system call of an OS takes a message as an argument, which is passed to a device driver. The device driver operates the device according to the passed message. For example, for writing a program for controlling the device in the C language, a system call, such as open( ), close( ), read( ), write( ), ioctl( ), or the like, is used. Such a system call controls, i.e., opens, closes, reads from, or writes into the device according to the message. Such system calls (i.e., functions) may provide similar functionalities on various OSs although names of the functions may vary depending on the OS or the execution environment. When a system call is called, a service of a kernel of the OS is invoked.
FIG. 7 is a block diagram showing a conventional device controller. A device 55 is operated by a device driver 562, which is linked to an OS 561. An application program 571 utilizes a high-level application programming interface (API) 572, which executes a system call 574. The OS 561 provides the system call 574 and the high-level API 572.
An interface of such a conventional device driver, which defines messages for the device driver and procedures to exchange messages to and from the device driver, has been publicly available in order to realize functionalities supported by the device. Furthermore, message interfaces have been standardized so that the same program can be executed for devices manufactured by different manufacturers without modifying the program, which has facilitated widespread use of devices.
When standardization of message interfaces is typically realized by defining a high-level API that is in a higher level than system calls, the high-level API is provided by the OS as a library or a dynamic link library (DLL). When an execution object calls the high-level API, the high-level API calls a system call to send a message to the device driver.
In general, a single instance of a device driver exists for a single device, and multiple instances of the high-level API exist for each application program. Such a single instance for each device driver is adapted in order to realize an exclusive access control in which a conflict is detected when multiple application programs try to control the device at the same time.
Portable telephone apparatuses have become available on the market which run such a general-purpose OS so that useful functionalities of the OS are utilized and various useful application programs running on the OS can connect to the wireless network of portable telephones and utilize the network.
In such apparatuses, a device that supports wireless telephone or data communication is coupled to a portable computer running the OS and an interface between the device and the OS is provided as a device driver. This technique offers various advantages. Examples include provision of publicly known means to control the device from an OS and application programs, and availability of a memory protection feature in an OS having such a memory protection feature that separates user spaces from the kernel space. In addition, portable telephone manufacturers can provide sophisticated functionalities while reducing the development cost of the OS. Furthermore, developers of OSs can eliminate extra labor to port an OS or application programs into different devices, thereby making latest high-performance devices available (see Japanese Unexamined Patent Application, First Publication No. H09-218844).
Device manufacturers and portable telephone manufacturers want to allow access to some functionalities of the device to the OS or trusted software programs while restricting the access from untrusted software programs, such as user applications, which is realized with a device controller or a method for controlling a device using conventional device drivers. That is, if usage of system calls, such as open( ), close( ), read( ), write( ), ioctl( ), by an execution program is permitted, even an untrusted software program can operate the device. For example, although operations that can interfere with the operation of the device, operations that charge fees to a user, or operations that read personal information of the user via an untrusted software program should be restricted, such a selective restriction was hard to be realized.
When a message interface between a device driver and an execution object is standardized, it is possible for the OS to restrict by usage of a certain message. However, when a device-specific functionality is utilized while restricting the usage thereof, the OS should handle respective conditions, which requires modification of the OS in many cases. Modification of the OS by the OS developer for restricting access to the device is not a practical solution.